Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-124.txt

Text File | 1994-12-08 | 43.3 KB | 1,160 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 26 Jun 92       Volume 1 : Issue 124

Today's Topics:

    Programming Question
    THINK Pascal Random Numbers
    Choosing a file at random.
    Motif programming- guides for Macintosh programmers
    Problem with C++ example code
    Technical Notes
    PBHCopyFile equivalent for non-shared environments?
    what's an OO-OS?
    SFGetFile quick question!!!
    Pascal stuff for sale
    A Couple of Strange Things About Think Pascal 4.01


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Stephen Jones)
Subject: Programming Question
Date: 11 May 92 14:01:09 GMT
Organization: University of Tennessee, Knoxville

Thanks to all those who responded to my first query.
  More Questions :

1. How would one go about displaying a push button in color ?  I have a
client who wants a green, a red and a black push button to be displayed
on the screen together.  Is this possible, and/or does anyone have any
ideas ?  Is this an Apple Interface Guideline violation ?

2. Has anyone experienced a peculiar error on the Classic II (or any
other machine for that matter) where SFPutFile, and SFGetFile will work
from the hard drive but not from a floppy drive ? Once the error occurs
no future calls to either one of these traps will work from the hard
drive or the floppy.  After it occurs, no application that uses these
calls will work.  They crash with an "unknown" error.  The system
attempts to display the dialog and crashes in the process of doing so.
Any ideas would be greatly appreciated.

                             Thanks in advance,
                                   Stephen Jones

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Mon, 11 May 1992 17:38:29 GMT

[e-mail] (Stephen Jones) writes:
>
>1. How would one go about displaying a push button in color ?  I have a
>client who wants a green, a red and a black push button to be displayed
>on the screen together.  Is this possible, and/or does anyone have any
>ideas ?  Is this an Apple Interface Guideline violation ?

It's "legal" if (1) color is not the only means by which any information
is conveyed, and (2) colorblind people can distinguish the colors as
easily as noncolorblind people.  Read IM V, ch. 2, for a good discussion
of colorblindness.

And yes, it's possible.  But it looks ugly as sin, especially with the
standard Apple push buttons.  If it were me, I'd at least make the
colored buttons different-looking somehow.  But if you must, read IM V,
ch. 12, to see how to do it.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Ceci n'est pas une .signature.

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 12 May 1992 01:33:39 GMT

[e-mail] (Jamie R. McCarthy) writes:
>[e-mail] (Stephen Jones) writes:
>>
>>1. How would one go about displaying a push button in color ?  I have a
>>client who wants a green, a red and a black push button to be displayed
>>on the screen together.  Is this possible, and/or does anyone have any
>>ideas ?  Is this an Apple Interface Guideline violation ?
>It's "legal" if (1) color is not the only means by which any information
>is conveyed, and (2) colorblind people can distinguish the colors as
>easily as noncolorblind people.  Read IM V, ch. 2, for a good discussion
>of colorblindness.

Additionally,from your descriptin,I think it's a bad idea. Somewhere in
Apple's UI docs is a discussion specifically about using red and green
in their symbolic forms (red=bad, green=good), so that the "Yes" button
in "Do you really want to reformat your hard disk?" dialog would be red,
and the "No" button green. Trouble is, they found out that red is especially
bright and attracts attention to itself, thus making it worse for the
inexperienced user. Since you specifically mention red and green, I assume
that it's this kind of situation.

Sorry about the incoherence of the post, but I'm tired and jetlagged and
running on no sleep.

- ---
- -Ivan Cavero Belaunde
DiVA Corporation

[e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 13 May 92 05:50:40 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Ivan M CaveroBelaunde) writes:
>
> [e-mail] (Jamie R. McCarthy) writes:
> >[e-mail] (Stephen Jones) writes:
> >>
> >>1. How would one go about displaying a push button in color ?  I have a
> >>client who wants a green, a red and a black push button to be displayed
> >>on the screen together.  Is this possible, and/or does anyone have any
> >>ideas ?  Is this an Apple Interface Guideline violation ?
> >It's "legal" if (1) color is not the only means by which any information
> >is conveyed, and (2) colorblind people can distinguish the colors as
> >easily as noncolorblind people.  Read IM V, ch. 2, for a good discussion
> >of colorblindness.
>
> Additionally,from your descriptin,I think it's a bad idea. Somewhere in
> Apple's UI docs is a discussion specifically about using red and green
> in their symbolic forms (red=bad, green=good), so that the "Yes" button
> in "Do you really want to reformat your hard disk?" dialog would be red,
> and the "No" button green. Trouble is, they found out that red is especially
> bright and attracts attention to itself, thus making it worse for the
> inexperienced user. Since you specifically mention red and green, I assume
> that it's this kind of situation.

I think an additional reason against this sort of color coding (if that is
really what you are doing) is that other cultures associate different meanings
to the common red & green which we see in traffic lights every day.

I seem to recall reading this in an HI document somewhere sometime.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Macknik)
Organization: University of Hawaii, College of Engineering
Date: Mon, 25 May 1992 13:16:13 GMT

In article <[e-mail]> [e-mail] (Ivan M CaveroBelaunde) writes:
>[e-mail] (Jamie R. McCarthy) writes:
>>[e-mail] (Stephen Jones) writes:
>>>
>>>1. How would one go about displaying a push button in color ?  I have a
>>>client who wants a green, a red and a black push button to be displayed
>>>on the screen together.  Is this possible, and/or does anyone have any
>>>ideas ?  Is this an Apple Interface Guideline violation ?

>>It's "legal" if (1) color is not the only means by which any information
>>is conveyed, and (2) colorblind people can distinguish the colors as
>>easily as noncolorblind people.  Read IM V, ch. 2, for a good discussion
>>of colorblindness.
>
>Additionally,from your descriptin,I think it's a bad idea. Somewhere in
>Apple's UI docs is a discussion specifically about using red and green
>in their symbolic forms (red=bad, green=good), so that the "Yes" button
>in "Do you really want to reformat your hard disk?" dialog would be red,
>and the "No" button green. Trouble is, they found out that red is especially
>bright and attracts attention to itself, thus making it worse for the
>inexperienced user. Since you specifically mention red and green, I assume
>that it's this kind of situation.

Since the most common form of colorblindness is red-green colorblindness,
these two colors are a particularly bad choice to differentiate tasks.
Don't rely on your users being able to tell these colors apart.

However, remember that the Apple UI is a guide for making your programs
consistent and understandable to most users.  If you have a specialized
group of users and a very important reason for not following the
guidelines, it can improve your program.

For example, if I was running a simulation of a piece of equipment that
had red and green buttons, I would want those buttons to be the same
color on the Mac; especially if the program was written to train users
about some aspect of the equipment.  Since the users would already be
familiar with the equipment, or need to become familiar with it through
initial training on a Mac, it would not be wrong to violate the UI to
emulate the equipment.

This works in any situation where you have a group of users who you can
assume has a certain set of knowledge.  But, If you are not absolutely sure
that your user base has that knowledge--assume they don't!  Usually this
will only apply in a custom programming environment, if you are programming
for the general public, stick to the UI.



---------------------------

From: [e-mail] (DAVID BONAR)
Subject: THINK Pascal Random Numbers
Organization: News and Views from LSU
Date: Wed, 13 May 1992 19:54:53 GMT


    I'm attempting to write a Monte Carlo engine for various simulation
purposes.  However, I have not found a way to get a reasonable random number
from THINK Pascal.  The manuals seem worthless for this (or I can't find it
if they have a mention) and I do not have access to Inside Mac or the like.
I'm looking for a means of getting a random sequence of numbers that does not
need to be seeded each time (such as a routine based on the clock).

Dave
__________
Dave Bonar
[e-mail]
__________


+++++++++++++++++++++++++++

From: [e-mail] (Bill Lipa)
Date: 13 May 92 22:38:35 GMT
Organization: Stanford School of Medicine


There is a random number generator provided as part of the Toolbox (it is
called Random() and for some reason is in Inside Macintosh I under QuickDraw).
However, as I have never read anything about the quality or speed of this
generator, I would recommend that you write your own. It is very easy to do.
Knuth vol. 2 has an interesting chapter about how to do it properly.

One interesting and fast generator he discusses is on p. 26. It doesn't
require any multiplications.

I am not clear on what you meant by
> I'm looking for a means of getting a random sequence of numbers that does not
> need to be seeded each time (such as a routine based on the clock).

Why is it important whether or not the routine needs to be seeded?

Bill
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (David Fry)
Date: 14 May 92 07:46:43 GMT
Organization: Harvard Math Department

In article <[e-mail]> [e-mail] (Bill Lipa) writes:
>
>There is a random number generator provided as part of the Toolbox (it is
>called Random() and for some reason is in Inside Macintosh I under QuickDraw).
>However, as I have never read anything about the quality or speed of this
>generator, I would recommend that you write your own. It is very easy to do.
>Knuth vol. 2 has an interesting chapter about how to do it properly.

It seems like I post this once a month, but...

While the Knuth chapter is indeed fantastic, the Mac's RNG is quite
good.  It is based on the routine described in "Random Number
Generators: Good Ones are Hard to Find" by Park and Miller in
Communications of the ACM, October 1988.  This article has a lot to
say about RNG, and why this one, which they call the "minimal
standard," is adequate for most purposes.

To be precise, Random() uses the lower 16 bits of the full 32-bit long
word used by the minimal standard.  However, you can get the full
32 bits by ignoring the result of Random(), and using randSeed as your
random number.

Also, I wrote my own (unoptimized) version of the same routine in THINK C,
and while it gave the same results as Random(), Apple's Random() was
much faster.  So, why re-invent the wheel?  Let them do the work for you.

David Fry                               [e-mail]
Department of Mathematics               [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138

+++++++++++++++++++++++++++

From: [e-mail] (J. S. Greenfield)
Organization: Syracuse University, CIS Dept.
Date: Fri, 15 May 92 01:41:33 EDT


>There is a random number generator provided as part of the Toolbox (it is
>called Random() and for some reason is in Inside Macintosh I under QuickDraw).
>However, as I have never read anything about the quality or speed of this
>generator, I would recommend that you write your own. It is very easy to do.
>Knuth vol. 2 has an interesting chapter about how to do it properly.

Better yet, check out

S. Park and K. Miller, "Random Number Generators: Good ones are hard to find,"
CACM, 31:10 (October, 1988).

If you want to do any serious simulation, then you need to be very careful
about selecting a random number generator.  Park and Miller have done all
the work for you (unless you are writing a simulation that requires
billions of pseudo-independent random events), and their paper will be
far easier to handle than Knuth's stuff.  (They both use the same type
of generator anyway--a "multiplicative linear congruential generator.")

>One interesting and fast generator he discusses is on p. 26. It doesn't
>require any multiplications.

In this day and age, I seriously doubt that this is of any real concern.
Remember that Knuth's stuff dates back to the late sixties.

>I am not clear on what you meant by
>> I'm looking for a means of getting a random sequence of numbers that does not
>> need to be seeded each time (such as a routine based on the clock).
>
>Why is it important whether or not the routine needs to be seeded?

It is probably *not* a good idea to avoid using your own seed, at least at
the outset.  Taking advantage of the deterministic nature of the
psuedo-random number generator (when an identical seed is used) can be an
important tool for debugging simulations.  If you use a varying seed, you
lose reproducibility (of some errors).

Later, you can always write a simple routine to check the clock and create
a "random" initial seed each time you run the simulation.

Good luck!

- --
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 17 May 92 22:56:25 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(David Fry) writes:
>
> In article <[e-mail]>
[e-mail] (Bill Lipa) writes:
> >
> >There is a random number generator provided as part of the Toolbox (it is
> >called Random() and for some reason is in Inside Macintosh I under
QuickDraw).
> >However, as I have never read anything about the quality or speed of this
> >generator, I would recommend that you write your own. It is very easy to do.
> >Knuth vol. 2 has an interesting chapter about how to do it properly.

> Also, I wrote my own (unoptimized) version of the same routine in THINK C,
> and while it gave the same results as Random(), Apple's Random() was
> much faster.  So, why re-invent the wheel?  Let them do the work for you.

Yes, I also had the assumption that a memory-based routine is faster than
a trap call (Random), I wrote some test code and the difference was so minimal
it's not worth implementing. The only reason one might write another Random
routine is for a particual random implementation concerning the quality of
random values (or as Knuth stated, a Random number is not random).

I placed my quick C++ test hack on the Developer CD, it's also on the
ftp.apple.com
somewhere in the snippets directory. The other nice thing with this small C++
class
is that it shows how to switch algorithms/member functions using pointers to
member functions.

Cheers,
Kent/DTS

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 18 May 92 00:53:22 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
>
> ... The only reason one might write another Random
> routine is for a particual random implementation concerning the quality of
> random values (or as Knuth stated, a Random number is not random).

Not so.  The _real_ only reason to write one is for use in a code segment
that doesn't have access to A5 globals, which Random calls.  Thus, if you
do not call InitGraf, you cannot use Random!

Example code segments where this might be needed are INITs, cdevs & FKEYs.

Jon

particual - particular - close, but no R.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 18 May 92 01:33:12 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Jon Pugh) writes:
> In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
> > ... The only reason one might write another Random
> > routine is for a particular random implementation concerning the quality of
> > random values (or as Knuth stated, a Random number is not random).

> Not so.  The _real_ only reason to write one is for use in a code segment
> that doesn't have access to A5 globals, which Random calls.  Thus, if you
> do not call InitGraf, you cannot use Random!

> Example code segments where this might be needed are INITs, cdevs & FKEYs.

I stand corrected, forgot InitGraf, actually I've seen problems where
people forget to call InitGraf before using Random (like faceless
background apps, which should call InitGraf anyway to initialize the
A5-world.

So feel free to use my C++ class for INITs :-). It's small enough so
it could be a stack-based one, then again it takes some time to initialize
it...


Cheers,
Kent
PA: Jon, what are you doing at the office today (Sunday), go home.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 19 May 92 17:31:15 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Kent Sandvik) writes:

   PA: Jon, what are you doing at the office today (Sunday), go home.

He probably got so much flak for specification and targetting
of AppleEvent destinations that he tries to do something about
it ... NOT ! :-)

- --
h++ - new and improved !

You never hide the menu bar. You might go about and make it the same
color as the background, but you never hide the menu bar.      - Tog

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 23 May 92 05:20:47 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Jon W{tte) writes:
>
> > [e-mail] (Kent Sandvik) writes:
>
>    PA: Jon, what are you doing at the office today (Sunday), go home.
>
> He probably got so much flak for specification and targetting
> of AppleEvent destinations that he tries to do something about
> it ... NOT ! :-)

Actually, NewsWatcher runs great over ARA at 9600 baud.  I can read news from
home now!

As for the Apple Event Manager, I didn't write it, don't have source code, and
don't really care.  You want to talk suite definitions, we can rock.  I do
like the T-shirt though.  Thanks, Jon!

Jon

---------------------------

From: [e-mail] (Stephen Jones)
Subject: Choosing a file at random.
Date: 21 May 92 13:28:25 GMT
Organization: University of Tennessee, Knoxville


  I'm writing an application that needs to search the directory in which
it is located, find the number of files of OSTYPE = 'STOK' and choose
one of them randomly.  How can my application find these files and Open
them.  Specifically,  how would it query the file manager to see if the
file type is the one being searched for, and how would it find the file
name of the chosen file.

    I hope this makes sense . . . .
                a d v a  Thanks  n c e,
                                            Stephen Jones

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 23 May 92 05:39:29 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Stephen Jones) writes:
>
>
>   I'm writing an application that needs to search the directory in which
> it is located, find the number of files of OSTYPE = 'STOK' and choose
> one of them randomly.  How can my application find these files and Open
> them.  Specifically,  how would it query the file manager to see if the
> file type is the one being searched for, and how would it find the file
> name of the chosen file.

Cycle through the files with PBGetCatInfo and count the ones with the correct
type.  Then choose a random number in the correct range.  Finally, cycle
through the files again and save the stats for the correct one.

Tough, huh?

Jon

---------------------------

From: [e-mail] (John Robinson)
Subject: Motif programming- guides for Macintosh programmers
Date: 21 May 1992 08:38:28 -0700
Organization: University of Southern California, Los Angeles, CA

Does anyone know of a reference which compares X-windows programming
to Macintosh programming?  I'm a Mac programmer bootstraping up into
the Motif world.  I know that events are handled quite differently
between Motif and the Mac; also, the Mac doesn't have anything called
a callback procedure.  Resources on the Mac are built with an inexpensive
resource editor called Resedit, which has a GUI; resources on Motif
require editing huge text files, and things get more complicated
because there are so many methods of building resource files (e.g. Wcl)
which define their own callbacks.  I don't see the connection between
the resources in these Wcl files and the applications they correspond to;
...

I get the feeling the Motif is more complex than the Mac (in that
it handles multiple platforms simultaneaously, not in its functionality)
but a side-by -side comparison of a sample application would get me going.
Thanks.

JR

+++++++++++++++++++++++++++

From: [e-mail] (Hugh Fisher)
Organization: Research School of Chemistry, ANU
Date: Fri, 22 May 92 00:12:43 GMT


  My $0.02 (Australian)... go for it, it is easier than you think.
  This applies to other Macintosh programmers as well: you have
  a head start over the Unix nerds when it comes to writing X
  applications.

  (Disclaimer: I write Athena X Toolkit stuff, not Motif, but
  this doesn't make much difference since they both work alike)

  To start, I'd recommend a book by Douglas A Young, "X Window
  Systems Programming and Applications with Xt" which comes in
  a Motif version. It shows you all the basic stuff of how to
  write an application, how to handle menus, buttons, etc.

  As to the differences, programming in Motif is equivalent to
  using MacApp on the Macintosh. The X Toolkit, which Motif is
  derived from, is layered on top of the "raw" X API, Xlib, just
  as MacApp is built on Quickdraw, the Event Manager, etc. If you
  are more comfortable with writing your own event loops and so
  on you should start with a book about Xlib.

  At this level, X looks very like the Macintosh. You open
  windows, draw lines, bit-blit things around, and wait for
  events to come in just as you do on the Mac. What X doesn't
  have is built in menu managers, scrollbars, etc. These are
  handled by the Toolkit.

  A toolkit such as Motif just takes care of all the hackwork
  you have to write in any application: event loops, updates,
  and so on. Callbacks are just the functions you would write
  to handle menu choices, dialog items, etc in a Mac app. It
  also provides basic building blocks like buttons and menus.

  In many ways, X applications are much cleaner than Macintosh
  ones. The API and behaviour are identical for everything:
  menus, commands, dialog items...none of the dialog hook vs
  MDEF vs CDEF stuff you have to remember on the Macintosh.

  Resources...yeah, there are a lot of them. This is because the
  X people couldn't hardcode the behaviour and appearance into
  ROM and decree "this is how it will be" like Apple did. You
  don't have to use them all though, a lot of applications get
  by with the defaults that the toolkits supply.

  On the other hand, Motif does seem to suffer from bloat. A
  popular .sig on the X newsgroups for a while was "While you
  are reading this, Motif grew by a kilobyte" I'd suggest
  starting with the Athena toolkit: smaller, and free.

    Hugh Fisher
    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Sak Wathanasin)
Date: 25 May 92 10:04:50 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John Robinson) writes:

> Does anyone know of a reference which compares X-windows programming
> to Macintosh programming?

There was an article in April 91 issue of MacTutor (vol 6 no 4) by Paul
Hyman called "X Windows for Mac Programmers". Has sample code for a "Hello
World" appl.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

uucp:      ...!uknet!nan!sw  Phone: [phone]
AppleLink: NAN.LTD           Internet: [e-mail]

---------------------------

From: [e-mail] (Brian Moore)
Subject: Problem with C++ example code
Date: 22 May 92 16:05:57 GMT
Organization: University of Michigan EECS Dept., Ann Arbor, MI

I was wondering if anyone could help me out with this problem.  I am
using the 'Elements of C++ Macintosh Programming' book by Dan Weston.
When I tried to type in the example code for the TApp object, the compiler
gave me an error about

     File "TApp.h"; line 149 # error:  function returning array

The declaration from the header file looks like this.

     virtual SFTypeList GetFileTypesList(void){ return (SFTypeList )nil; }

Which is exactly how it shown in the book.  Now I know you can't return an
array from a function like this, but since this is an example program I was
thinking maybe I'm missing something.  Is anybody out there who used this
book and remembers how it is supposed to look.  I am using MPW 3.2.2 with
MPW C++ 3.2 from the ETO 7 CD.

On a related note, I remember there being something on the net that had
the source code for this book for Think C or MPW ( don't remember which )
I tried to use Archie to find it but it did't come back with it.  I
think it was called ElofC++Prog.hqx or something like that.  Does anybody
have this or know where I can get it?


Thanks,
Brian Moore
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 22 May 92 20:43:11 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Brian Moore) writes:
>      File "TApp.h"; line 149 # error:  function returning array
>
> The declaration from the header file looks like this.
>
>      virtual SFTypeList GetFileTypesList(void){ return (SFTypeList )nil; }
>
> Which is exactly how it shown in the book.  Now I know you can't return an
> array from a function like this, but since this is an example program I was
> thinking maybe I'm missing something.

Arrays could be very costly anyway, so pass a pointer or reference back from
the call.
- --
                                              Cheers, Kent


---------------------------

From: [e-mail] (Alan Akins)
Subject: Technical Notes
Organization: Somewhere Over the Rainbow, in a little town in the Willamette
Date: Sat, 23 May 1992 19:09:34 GMT

I am one of those people who didn't have access to ftp not long ago, so I took
a subscription to the DTS Technical Notes for the Mac.  I received March just
fine, but have not yet received the May mailing (it is bi-monthly, right?).

Has anyone who subscribes received theirs? or knows why we haven't gotten them
yet?

tank-u
Alan

- --
*                                          | Alan Akins: [e-mail] *
*       "Forests aren't wheatfields,       | University of Oregon          *
*     just as a radio isn't             | Department of Computer and       *
*               a toaster with words."     |     Information Sciences          *

+++++++++++++++++++++++++++

From: [e-mail] (Andy Peterman)
Date: 24 May 92 07:39:37 GMT
Organization: The Treehouse

In article <[e-mail]> [e-mail] (Alan Akins) writes:
- ->I am one of those people who didn't have access to ftp not long ago, so I took
- ->a subscription to the DTS Technical Notes for the Mac.  I received March just
- ->fine, but have not yet received the May mailing (it is bi-monthly, right?).
- ->
- ->Has anyone who subscribes received theirs? or knows why we haven't gotten them
- ->yet?

I called them (APDA) Friday wondering about the same thing.  He said
that they were still putting together the printed version for mailing,
but did not say when they would go out.  Sounds like it may be a few
weeks yet :-(.

- --
Andy Peterman
treehouse![e-mail]
[phone]

---------------------------

From: [e-mail] (J. S. Greenfield)
Subject: PBHCopyFile equivalent for non-shared environments?
Date: 23 May 92 19:04:09 GMT
Organization: Syracuse University, CIS Dept.

Howdy folks.  I was just wondering if there is a procedure call analogous to
PBHCopyFile that works for non-shared environments.  I haven't yet found
anything in IM.

Incidentally, has anybody noticed that in IM V, the description of the
procedure call for PBHCopyFile specifies that there is a field in the
parameter block called ioFileName?  However, there is no such field name
defined in the data structure, and THINK Pascal 4.0.1 flags the field as
undeclared.

What gives?  Am I missing something?

Email or post replies.  Thanks for any help.

- --
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"

+++++++++++++++++++++++++++

From: [e-mail] (Kent P Miller)
Date: 24 May 92 22:16:21 GMT
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA

In article <[e-mail]> [e-mail] (J. S. Greenfield) writes:
>Incidentally, has anybody noticed that in IM V, the description of the
>procedure call for PBHCopyFile specifies that there is a field in the
>parameter block called ioFileName?  However, there is no such field name
>defined in the data structure, and THINK Pascal 4.0.1 flags the field as
>undeclared.
Greeny,

That has got to be the most poorly documented routine in the IM world!

Anyway, the ioFileName should really be ioNewName.  The other paremeters
don't work like you would expect (at least not me!).

Here's how to make it work:

        with pb3 do
            begin
                ioCompletion := nil;
                ioNamePtr := @u;
                ioVRefNum := pb.iovrefnum;
                ioDstVRefNum := pb.iovrefnum;
                ioNewName := nil;
                ioCopyName := @t;
                ioNewDirID := pb2.ioFLParID;
                ioDirID := pb2.ioFLParID;
            end;
        dupeFile := PBHCopyFile(@pb3, false);

the pb2 was filled in with PBGetCatInfo on the dest file (I think).

Good luck!


- --
- -----------------------
Kent Miller
[e-mail]
- -----------------------

---------------------------

Subject: what's an OO-OS?
From: [e-mail]
Date: 24 May 92 16:49:13 CST
Organization: University of Missouri-Kansas City

In article <[e-mail]>, [e-mail] (Larry Meyer - mac weenie) writes:
>... does anyone out there have any idea what an
> object oriented operating system is? If so, please tell me!


One can sure speculate. Hopefully one where I can drop in my
own file system, plug in my own display system, plop down my own
memory manager, stick in my own process scheduler, ...

Especially nice would be dynamic binding of those objects, so
I wouldn't have to write a *new* file system, but could add to
the current file system's functionality in an otherwise transparent
way.


Jonathan/[e-mail]

---------------------------

From: [e-mail] (Anthony VanAlphen 1572587)
Subject: SFGetFile quick question!!!
Organization: Bell Northern Research, Ottawa
Date: Mon, 25 May 1992 16:51:53 GMT

If SFGetFile returns the fName and the vRefNum how can I convert this
to a ":" delimited filename ie AVA:Desktop:foldera:fileb so that I can
pass this expression to a STDIO fopen function.
- --
- -----------------------------------------------------
Anthony Van Alphen
Bell-Northern Research       Phone:    [phone]
P.O. Box 3511 Stn. C.        Fax:      [phone]
Ottawa, Ontario K1Y 4H7      Internet: [e-mail]
- -----------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Kent P Miller)
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA
Date: Mon, 25 May 1992 20:45:04 GMT

In article <[e-mail]> [e-mail] (Anthony VanAlphen 1572587) writes:
>If SFGetFile returns the fName and the vRefNum how can I convert this
>to a ":" delimited filename ie AVA:Desktop:foldera:fileb so that I can
>pass this expression to a STDIO fopen function.
Sorry to post twice in one day, but I answered this question a few weeks
ago and since then I have found a bug in the code I posted.  The code worked
fine for filenames on local volumes, but had a problem with shared volumes.

I got these parameters from a StandardGetFile (returns an FSSpec) but it
should work under system 6 SFReply.

  function GetFullPath (name: str32; parID: integer; vRefNum: integer): str255;
   var
    tempName, thePath, comppath: Str255;
    vParams: CInfoPBRec;
    theError, theErr: OSerr;
    i: integer;
    pb: HParamBlockRec;
  begin
   thePath := '';
   tempName := '';
   with vParams do
    begin
     ioCompletion := nil;
     ioNamePtr := @tempName;
     ioVRefNum := vRefNum;
     ioFDirIndex := -1;
     ioDrDirID := parID;
     repeat
      theError := PBGetCatInfo(@vParams, FALSE);
      if (theError = noErr) then
       begin
       pb.ioNamePtr := @tempname;
       pb.ioVRefnum := parID;
       pb.ioFileID := ioDRParID;
       theErr := PBResolveFileIDRef(@pb, false);
       if theErr = noErr then
         ioDRDirID := pb.ioSrcDirID
       else
          ioDRDirID := ioDRParID;
       thePath := concat(tempName, ':', thePath);
       tempName := '';
       end;
     until (theError <> noErr);
     tempName := concat(thePath, name);
     GetFullPath := tempName;
    end;
  end;
- --
- -----------------------
Kent Miller
[e-mail]
- -----------------------

---------------------------

From: [e-mail] (Steven Polsky)
Subject: Pascal stuff for sale
Date: 12 May 92 02:01:01 GMT
Organization: Colorado SuperNet, Inc.


I have the following PASCAL software, books, and disks for sale:
- ---------------------------------------------------------
IBM SOFTWARE
- -----------------------------------
Turbo Pascal Professional v6.0
mail order $ 209 + shipping
my price $150 incl shipping
- ------------------------------------
Turbo Pascal for Windows
mail order price $169 + shipping
my price $125 incl shipping
- ------------------------------------
MACINTOSH SOFTWARE
- ------------------------------------
THINK Pascal v4.0
mail order $165 + shipping
my price $125 incl shipping
- ------------------------------------
Just Enough Pascal
free with purchase of THINK Pascal
- ------------------------------------
PASCAL BOOKS AND DISKS
- ------------------------------------
Macintosh Pascal Programming Primer,
Volume 1 including disk
reg. price $45
my price $25 incl shipping
- ------------------------------------
Object-Oriented Programming Power
For THINK Pascal Programmers
reg. price $40
my price $25 incl shipping
- -------------------------------------
Oh! Pascal! second edition and
THINK Pascal supplement
reg. price $37
my price $20 incl shipping
- -------------------------------------

send replies via e-mail or phone.

Steven Polsky
voice mail: 303-893-0123

+++++++++++++++++++++++++++

From: [e-mail] (Steven Polsky)
Date: 25 May 92 22:40:50 GMT
Organization: Colorado SuperNet, Inc.


I have the following PASCAL software, books, and disks for sale:
- ---------------------------------------------------------
MACINTOSH SOFTWARE
- ------------------------------------
THINK Pascal v4.0
mail order $165 + shipping
my price $125 incl shipping
- ------------------------------------
Just Enough Pascal
free with purchase of THINK Pascal
- ------------------------------------
PASCAL BOOKS AND DISKS
- ------------------------------------
Macintosh Pascal Programming Primer,
Volume 1 including disk
reg. price $45
my price $25 incl shipping
- ------------------------------------
Object-Oriented Programming Power
For THINK Pascal Programmers
reg. price $40
my price $25 incl shipping
- -------------------------------------
Oh! Pascal! second edition and
THINK Pascal supplement
reg. price $37
my price $20 incl shipping
- -------------------------------------

send replies via e-mail or phone.

Steven Polsky
[e-mail]
voice mail: 303-893-0123

---------------------------

From: [e-mail] (P. Hawthorne)
Subject: A Couple of Strange Things About Think Pascal 4.01
Date: 18 May 92 23:38:06 GMT
Organization: Reed College, Portland OR


    I just spent a fair amount of time tracking down a bug in a Think
Pascal project that would seem to be the fault of Think Pascal itself.
Perhaps not surprisingly, it has to do with boolean variables. What
surprises me is that I actually found and stamped out the little beasty...
Thank the stars for the Think Pascal debugging environment!

    I had already discovered some trivial problems with autoscrolling
source windows, cancelling out of some dialogs with command dot, and some
minor unrecoverable heap fragmentation. Since they did not ultimately
affect the final product, I chose to grin and bear it.
    (Actually, I am still having some problems with Think Pascal source
and debugging windows confusing my floating window code all of a sudden
after upgrading to 4.01, but the burden of correction is probably mine on
that one.  The windowKinds must have gotten changed or something. Either
that or Pascal isn't catching mouseDown events during testing quite
correctly these days.)

    However, problems began to appear that I have tracked down to an
object which maintains an array of booleans. It worked perfectly before
updating to version 4.01.
    While I may be mistaken and I hope I do not have to eat my hat, I
seem to recall that the size of a boolean was 2 bytes before version 4.01.
Now, not only does the SizeOf routine return a value of 1 byte, but there
has been a very subtle bug scurrying around my graph traversal code which
has nothing to do with my code as far as I can tell. I do my development on
an SE/30, and should not be having any problems with using an odd address,
so that shouldn't be it.
    The new size of booleans should be cool, because the array object
takes the size of the items that it keeps from the SizeOf routine and can
cope with any size. It gets and sets the value of each item in the array
with solid memory copying code that I have verified. I have even resorted
to, horror of horrors, using BlockMove just to be sure.

    Is this a known bug? I have switched the code in question from
booleans to integers, and it works just swell. I can probably recreate the
bug if necessary, but would like to know if it has bitten anyone else...
    Or, alternately, whether it has to do with the phase of the moon
and my shoe size and is really my fault after all.

    Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 19 May 92 01:46:38 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>    While I may be mistaken and I hope I do not have to eat my hat, I
>seem to recall that the size of a boolean was 2 bytes before version 4.01.

Heinz 57 sauce goes well with felt, straw, or leather. The size of a Boolean
is, and always has been, one (1) byte.

R.


- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer, Quickdraw Group
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 23 May 92 05:29:24 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Rich Siegel) writes:
>
> In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
> >    While I may be mistaken and I hope I do not have to eat my hat, I
> >seem to recall that the size of a boolean was 2 bytes before version 4.01.
>
> Heinz 57 sauce goes well with felt, straw, or leather. The size of a Boolean
> is, and always has been, one (1) byte.

The trick is that if you pass a Boolean, it puts 2 bytes on the stack
to keep the stack word-aligned.  This makes Booleans _appear_ to be two bytes
long.  Records can also cause this sort of alignment to occur.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 25 May 92 09:30:59 GMT
Organization: Reed College, Portland, Oregon


  [e-mail] (P. Hawthorne) writes:
: While I may be mistaken and I hope I do not have to eat my hat, I seem to
: recall that the size of a boolean was 2 bytes before version 4.01.

  [e-mail] (Rich Siegel) writes:
: Heinz 57 sauce goes well with felt, straw, or leather. The size of a Boolean
: is, and always has been, one (1) byte.

  [e-mail] (Jon Pugh) writes:
: The trick is that if you pass a Boolean, it puts 2 bytes on the stack to
: keep the stack word-aligned.  This makes Booleans _appear_ to be two bytes
: long.  Records can also cause this sort of alignment to occur.

  I'm afraid I've already eaten the hat, but thanks for the vindication, Jon.
Solved the problem by using a bit vector rather than a boolean array, which
was my original intention anyway.

  One of the other things I mentioned has been straightened out, too. I've
finally gotten a setjmp/longjmp implemented that's getting along with the
debugging environment in Think Pascal.

  That was right before something blew away the extents b-tree header on my
hard drive today. No rest for the weary...

  Theus ([e-mail])

---------------------------

End of C.S.M.P. Digest
**********************